The boxel-cli integration test suite covers the publish/unpublish and
readiness-check HTTP contract the realm-server exposes. CS-11161 was the
result of a realm-server-only PR changing /_publish-realm from a
synchronous 200 to an async 202 + poll model without anything tripping in
that PR's CI — boxel-cli-test only ran when packages/boxel-cli/** files
changed. Widening the trigger to also include realm-server changes makes
that class of drift fail pre-merge.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Extracts `publishCliOptsToOptions` so the Commander-flag → PublishOptions
translation is testable without a realm-server. The new tests would have
caught the CS-11161 bug class: they assert (a) Commander populates the
positive `wait` / `republish` keys for negated flags (not `noWait` /
`noRepublish`), and (b) the translation lowers `--no-wait` to
`waitForReady: false` and `--no-republish` to `republish: false`.

The integration tests exercise the programmatic publishRealm() API only
and missed both halves.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The realm-server-url input description claimed defaults were inferred
for stack.cards / boxel.ai / localhost, but this action's own inference
block only knows the two CI environments and hard-fails otherwise.
Localhost works fine in workspace-sync and unpublish-preview-realm
because they forward to _setup-boxel-cli without inferring a URL
themselves, but here the action needs the URL to compose the source-
realm URL. Documenting the actual contract rather than expanding the
inference, since no CI workflow invokes this against a localhost
matrix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Mirrors the boxel-cli-test stack setup (build host/icons/ui via the
reusable test-web-assets workflow, start matrix, register realm users,
boot the dev services) and then invokes publish-preview-realm,
workspace-sync, and unpublish-preview-realm against the local stack —
referencing each action at @\${{ github.sha }} the same way a real
consumer would. Delete this workflow once a successful run is captured.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

GitHub Actions doesn't allow expressions in a workflow step's `uses:`
ref — only literal strings. The `github.action_ref` expression that
works in the actions' own internal `uses:` clauses is evaluated by a
different parser context (composite-action steps) and isn't usable
here. The demo workflow only runs on this branch anyway, so pinning to
the branch name resolves to the latest pushed tip at run time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…space-sync-action

The realm-server and vite host both speak HTTPS+HTTP/2 only (the
prerenderer needs HTTP/2 multiplexing, see infra:ensure-dev-cert). The
previous demo workflow's http:// probe and http:// action inputs would
never match the running services — the readiness loop spun for 10
minutes and timed out. Update the probe to mirror boxel-cli-test
(curl -sk + %{http_code} check) and pass https://localhost:4201/ to the
action inputs.

Matrix stays on http://localhost:8008 — synapse doesn't terminate TLS
locally.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous setup wrote BOXEL_SRC/packages/boxel-cli/bin to
$GITHUB_PATH, but that directory holds the script named `boxel.js`
(the file package.json's `bin: { boxel }` maps to). Even when
$GITHUB_PATH did propagate, the next step would fail to find a
`boxel` binary. Symlinking the entry point into /usr/local/bin —
which is already on the default PATH — gives subsequent steps the
same `boxel` command that npm/pnpm-installed callers see.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

pnpm register-realm-users runs in realms-only mode and only registers
the REALM_USERS list — it skips EXTRA_USERS, which is where the
user/password account this demo authenticates as lives. Switch to
register-all so synapse has that account when boxel realm create
attempts a Matrix login (boxel-cli #4851 run failed with 403 because
the account never existed in synapse).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

register-all writes EXTRA_USERS into the boxel users table via
ensureUserRecord, so it requires postgres up — register-realm-users
(realms-only) doesn't. Add an explicit start:pg + wait-for-pg step
pair before the matrix-user registration, mirroring the order the
ci.yaml matrix-test job uses.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

register-all's ensureUserRecord step writes to the boxel users table,
but the boxel database is only created by the realm-server's
migrations on first boot. Without those migrations, register-all hits
'database "boxel" does not exist'. Run `pnpm migrate` (realm-server's
PgAdapter-driven migrator) between the wait-for-pg step and the
matrix-user registration to make the target schema exist.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The publish-preview-realm / unpublish-preview-realm / workspace-sync
composite actions and their TEMPORARY demo workflow have been split
off into their own PR + Linear ticket (CS-11180) so this PR can land
on the small CLI half without waiting on the ~30-min action demo
each iteration. The action files are preserved on the new branch
cs-11180-extract-shared-preview-realm-github-actions-to-monorepo,
which keeps the CLI commits in its ancestry so the demo can still
exercise the CLI from this PR while it's in review.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>